NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/1115

Text File | 1996-08-06 | 4.0 KB | 79 lines

Path: fido.asd.sgi.com!austern
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Newsgroups: comp.std.c++
Subject: Re: sample auto_ptr template
Date: 16 Apr 1996 13:15:34 PDT
Organization: GABI Software, Sarl.
Approved: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <4kcr2d$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 16 Apr 1996 09:28:26 GMT
In-Reply-To: [e-mail]'s message of 15 Apr 1996 14:22:46 PDT
Apparently-To: [e-mail]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMXP/50y4NqrwXLNJAQGwogH/VNppitukSWhXBmIJi+QyI4bDE2WiDMt/
    5MT4aMwbEYBd/zWO4D1odOzZnTPsnxHyOVNDX/vDrac+7nauZbmpCg==
    =GsG9
Originator: [e-mail]

In article <[e-mail]> [e-mail]
(David Vandevoorde) writes:

|> >>>>> "JK" == J Kanze <[e-mail]> writes:
|> [...]
|> JK> Well, I agree fully that it is bad programming practice to let
|> JK> exceptions propagate out of a destructor.  At present, however, it
|> JK> is legal C++ (although if the committee were to declare it
|> JK> undefined behavior, they wouldn't get any objections from me), and
|> JK> as such, should be taken into consideration when designing a
|> JK> *standard* library component.  (I *don't* take it into
|> JK> consideration when designing my own components.  But: if you don't
|> JK> like my style, you aren't obliged to use my components.  Everyone
|>                                                              ^^^^^^^^
|> JK> has to use the standard components, however.)
|>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> I would like to contest that ;-)

Yes.  I should have said: everyone should be able to use the standard
components.

|> Given the kind of overhead in the ``auto_ptr nouveau'', I'm unlikely
|> to want to use it... and nothing prevents me from that. As far as I
|> know, auto_ptr does not have any connections with the rest of the
|> language (i.e., if it were dropped, there would be no repercussions).
|> Furthermore, it's really not hard to fashion a auto_ptr-like template
|> that fits one's desired semantics.

|> In that light, it seems to me that a standard auto_ptr is a little
|> overkill... Fortunately, I'm not forced to use it and so don't care
|> too much.

The problem is one of maintainance.  I'm fairly sure that most of the
readers of this forum would have no difficulty crafting a variant of
auto_ptr which is exactly adapted to their particular style.  Doing so,
however, means one more thing to learn for anyone trying to maintain
your code.  So if the standard class comes anywhere close to what I
want or need, I will be using it, instead of my own.

Note that almost by definition, a standard class is not optimal for a
particular use.  What makes it valuable as a standard is that it is
adequate for a wide range of uses.  If some part of your application
makes intensive use of this class, you might want to declare a typedef,
to facilitate changing it later, if profiling really does show a
problem.  (My experience is that it's amazing how rarely such things
really are a problem, and that generally, they aren't what you were
expecting anyway.)
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:[e-mail]
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:[e-mail]
]